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REMARKS 

In response to the Final Office Action dated June 15, 2005, Applicant respectfully 
requests favorable reconsideration of the above-cap tioned application in view of the 
above-identified amendments and the following remarks. Claims 1-44 are now pending 
in this application. 

Status of Application 

To ensure entry of this Response, a Request for Continued Examination (RCE) is 
being filed concurrently herewith. 

Overview of Changes Made to the Claims 

This Response amends the preambles of claims 30-32 so that they conform to the 
format adopted by the other pending dependent claims. This Response also adds new 
dependent claims 33-44. 

Regarding the 35 U.S.C. §102 Rejection 

Claims 1-32 were rejected under 35 U.S.C. § 102(e) as being anticipated by U.S. 
Patent No. 6,785,21 to Immerman et al. (referred to below as "Immerman"). Applicant 
respectfully traverses this rejection for the following reasons. 

As a main thrust, hnmerman is directed to a system and method for distributing a 
run time model to a client for execution thereat (column 2, lines 29-31). To implement 
this feature, hnmerman discloses a Domino Off-line Service (DOLS) 62 that provides 
distributed computing and remote execution of various apphcations (column 5, lines 3-7). 
In operation, the DOLS 62 provides a way for browser users (at the client site) to utihze 
Domino Web application offline (column 20, lines 26-29). More specifically, using a 
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browser, a user can take an application offline, make changes, and synchronize those 
changes with the online apphcation (column 20, lines 29-32). To enable the apphcation 
for offline use, a Web site developer and a Web site administrator configure and set up 
the application (column 20, hues 46-48). Once the apphcation is enabled, the end user 
opens the online Web application. That is, by clicking on a control or an icon, the user 
downloads the application to a local machine (column 20, lines 53-55). The user may 
then interact with the offline application (column 20, lines 62-67). 

The Office Action relies principally on colunms 5 and 6 of hnmerman in rejecting 
most of the independent claims in the above-captioned application. That portion 
describes a local run time model 90. At the outset, it is important to note that the local 
run time model 90 refers to processing performed at a client site, not the server site. See 
for instance, column 2, lines 55-57, which states, "FIG. 2 is a diagram illustrating the 
objects unbundled to a local run time model in support of an API for client side execution 
ofNotes." 

The local run time model 90 comprises a hierarchy of models including object 
data store model 92, secimty model 96, indexing model 98, rephcation model 94, agent 
workflow model 99, and mail model 97 (column 5, lines 31-41). The data store model 92 
specifies the level of access that users and servers have to data elements (column 5, lines 
53-58), the security model 96 provides a collection of log-in credentials (column 5, line 
66), the indexing model 98 provides a search index which administrators and database 
managers may apply to databases and files (column 6, lines 15-19), the replication model 
94 provides a series of rules describing how to organize and synchronize databases 
(column 6, lines 25 and 26), the agent workflow model 99 implements the execution of 
an agent (column 6, lines 42 and 43), and the mail model 97 provides rules for 
forwarding information from one object data store location to another (column 6, lines 50 
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and 5 1). In this hierarchy, "the design of a parent model is a prerequisite to the design of 
a child model" (column 5, lines 47 and 48). hnmerman provides an example of what this 
means by stating that the "security model 96 is a prerequisite to mail model 97 in the 
sense that mail model 97 must provide for verification of the identity of users accessing 
mail model 97 with respect to a data object" (column 6, hnes 53-57). Fig. 2 shows the 
specific design dependencies of the above-identified models. 

The above-described subject matter is not even remotely related to what is being 
claimed in the present apphcation. Consider claim 1, which is reproduced below in its 
entirety. 

1 , A server system, comprising: 
one or more computers; 

an application executing on the computers to receive and process client requests; and 
a constraint system to constrain operation of the application according to multiple 
different constraints, the constraint system comprising a hierarchy of constraint layers, with each 
constraint layer containing a set of one or more constraints that customize operation of the 
application. 

First, the claim is directed to a "server system." The server system includes, in 
part, "an application ... to receive and process client requests." The claimed "constraint 
system" itself is an element of the "server system." In contrast, the cited portions of 
hnmerman disclose a "local run time model" deployed at the client site. Thus, the 
models described in colurnns 5 and 6 of Immerman pertain to client-side flinctionahty, 
not a constraint system employed by a server system which receives and processes client 
requests. 
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Second, claim 1 recites, in part, "a constraint system to constrain operation of the 
application according to multiple different constraints, the constraint system comprising a 
hierarchy of constraint layers, with each constraint layer containing a set of one or more 
constraints that customize operation of the application." Immerman discloses no such 
constraint system. In citing columns 5 and 6 of Immerman, the Patent Office is 
apparently of the opinion that the model hierarchy shown in Fig. 2 has a bearing on the 
claimed constraint system having a hierarchy of constraint layers. But, as summarized 
above, that hierarchy merely illustrates the design dependencies of different components 
of the local run time model 90; for example, the security model 96 is a prerequisite to 
mail model 97 in the sense that the mail model 97 must provide for verification of the 
identity of users accessing mail model 97 with respect to a data object. The models do 
not pertain to a constraint system which constrains or customizes the operation of an 
application as claimed. More specifically, the various models (92, 94, 96, 97, 98, 99) in 
Fig. 2 do not constrain or customize the operation of the local run time model 90, but 
rather the models make up (or comprise) the model 90 itself (see column 5, lines 31-41). 
That is, the models are integral parts of the local run time model 90, rather than 
constraints on some other, pre-existing and independent, appUcation. 

In response to this argument, the Final Office Action states, in part, that "There is 
no limitation in the claim on the fiinctionality of the constraint or how the constraint 
customizes the operation of the application and therefore Immerman meets the scope of 
the claimed hmitation 'a constraint system comprising a hierarchy of constraint layers 
that customizes the operation of the application'" (page 11, paragraph No. 3 of the Final 
Office Action). This position is misplaced because claim 1 does clearly distinguish over 
Immerman in its present form. For instance, the organization of models shown in Fig. 2 
of Immerman does not "customize operation of the application," according to the plain 
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meaning of the word "customize." According to one online dictionary, to "customize" 
means to "change to suit better: to alter something in order to make it fit somebody's 
requirements better," as in "She has customized the software to suit our needs" 
(htt p://encarta.msn.com/dictionarv /customize.html ). As explained above, the 
organization of models shown in Fig. 2 of Immerman controls the design dependency of 
the models. It does not change an application; it just defines how the models are put 
together. 

The Final Office Action also cites a portion of the Immerman 's abstract which 

states: 

DOLS provides a layered security model that allows flexibility for controlling access to all or part 
of an application. The highest level of security is managed through a database access control list 
(ACL). Further refinements within the security model provide access to specific documents, and 
their views, forms or folders, and include read access lists, write access lists, form access lists and 
readers and authors fields. 

The explanation in the October 14, 2005 Advisory Action elaborates on this argument by 
stating, in part, that "The security model may define the ability of a user to 'read or write 
acess' [sic] to the model and therefore customizes the operation of the application 
according to a security model 'constraint'." 

First, it is pointed out that, in making the rejection, the Patent Office is combining 
two different concepts together. As a first concept, the Office Action cites the 
organization of modules shown in Fig. 2. As a second concept, the Office Action cites 
the layered nature of the security module. Since these concepts do not address the same 
subject matter, it is not clear how the Office Action is proposing that these concepts be 
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interpreted in aggregate. As it stands, therefore, the rejection is internally inconsistent, 
and thus incoherent. 

Second, even if the cited passage (in the abstract) is applied for what it describes 
by itself, this passage fails to disclose the subject matter recited in claim 1. Inunerman's 
multi-layered security model refers to client-side functionality, not functionality deployed 
at a "server system" as claimed. For instance, note Fig. 5 of Immerman. This figure 
shows that the security model 80 is deployed as a client local replica, not as a component 
of a server system that receives and processes client requests. 

For at least the above reasons, the Apphcant respectfully submits that hnmerman 
neither discloses nor suggests the subject matter recited in claim 1 . 

Claims 2-8 depend from claim 1, and are therefore allowable for at least this 
reason. Moreover, each of these claims recites additional features which are not 
disclosed in, or suggested by, Immerman. 

For instance, claims 2-6 recite details of different constraint layers in the 
constraint hierarchy. Namely, claim 2 recites that the hierarchy comprises a constraint 
layer that contains legally mandated constraints to constrain operation of the apphcation 
according to legal principles. Claim 3 recites that the hierarchy comprises a constraint 
layer that contains company-mandated constraints to constrain operation of the 
application according to preferences of a company that operates the application. Claim 4 
recites that the hierarchy comprises a constraint layer that contains customer constraints 
to constrain operation of the application according to preferences of customers. Claim 5 
recites that the hierarchy comprises a constraint layer that contains cultural constraints to 
constrain operation of the application according to cultural aspects. And claim 6 recites 
that the hierarchy comprises a constraint layer that contains end user constraints to 
constrain operation of the application according to preferences of an end user. 
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To repeat, Immerman's Fig. 2 shows an object data store model 92, a security 
model 96, an indexing model 98, a replication model 94, an agent workflow model 99, 
and a mail model 97. These models have no bearing on the claimed constraint layers that 
contain legally mandated constraints, company-mandated constraints, customer 
constraints, cultural constraints, and end user constraints. Further, if, in the alternative, 
the Office Action is interpreting the claimed constraint system as Immerman's multi- 
layer security model, the AppHcant points out that different layers of a security model 
cannot be interpreted as the above-identified specific constraint layers. 

In rejecting these dependent claims, the Office Action also cites column 10, line 
30 to column U, line 28 of Immerman, as well as column 18, line 59 to column 19, line 
62 of Immerman. The excerpt in colunans 10 and 11 refers, in part, to an ID policy 
database 114 and an ID repository database 111. The excerpt in columns 18 and 19 
refers, in part, to a configuration document 232 having tabbed pages for basics tab 380, 
services tab 384, schedule tab 390, and rules tab 400. This excerpt also describes an 
offline security policy form 410, an application page 238, web control 241, and various 
other components 246-258. First, these topics do not have anything to do with the 
constraint layers recited in claims 2-6, namely, constraint layers pertaining to legally 
mandated constraints, company-mandated constraints, customer constraints, cultural 
constraints, and end user constraints. For example, the words "legal" and "cultural" do 
not appear anywhere in the Immerman document. Second, even if, assuming arguendo, 
that the information disclosed in these excerpts had some relevance to the claimed 
constraint layers (which it does not), Immerman does not describe that this information is 
arranged in a constraint hierarchy (as recited in claim 1). 

As to the recitation of specific constraint layers, the October 14, 2005 Advisory 
Action states, in part, "In fact, claim 3 states that the constraint is defined according to 
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the preferences of a company. In comparison, the security model is defined by the 
administrator and is therefore defined according to a company's preferences." First, the 
security model pertains to local functionality, not a constraint layer in a "server system." 
Second, the Office Action has not shown where Immerman states that an administrator is 
associated with a company. 

Dependent claim 7 recites that the constraint layers are organized within the 
hierarchy such that a first constraint layer limits a second constraint layer but the second 
constraint layer does not limit the first constraint layer. As described above, hnmerman's 
Fig. 2 refers to design prerequisites (that is, one component must be built for another 
component to work properly), rather than constraints in the context of the claimed 
invention. 

Dependent claim 8 recites that the server system (of claim 1) fiirther comprises a 
constraint resolver to resolve the constraint layers so that operation of the application is 
constrained by a sum of the constraints in the layers. Immerman discloses that the 
different models shown in Fig. 2 comprise the local run time model 90. There is 
absolutely no hint in Immerman that these models might conflict with each other. Hence, 
there is likewise no suggestion that Immerman' s system includes a constraint resolver to 
cope with such conflicts. Further, if the constraint layers are being interpreted as layers 
in a security model, there is no suggestion that these layers might conflict with each 
other, and thus no suggestion of a constraint resolver. 

Based on at least the above reasons, the Applicant respectfully submits that 
Immerman neither discloses nor suggests the subject matter recited in dependent claims 
2-8. 

The remaining previously pending claims (9-32) recite subject matter that is 
related to various permutations of the above-discussed subject matter (in claims 1-8). 
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Therefore these claims are allowable for reasons that are related to those given above. In 
addition, these claims recite additional subject matter which is not disclosed or suggested 
in hnmerman. 

Consider, for instance, independent claim 9. This claim is reproduced below in its 
entirety: 

9. A server system comprising: 
one or more computers; and 

a multi-layer application executing on the computers to handle client requests, the multi- 
layer application comprising: 

a problem-solving logic layer to process the client requests according to an associated 
problem domain, the problem-solving logic layer containing one or more execution models to 
perform various sets of tasks when processing the client requests, the problem-solving logic layer 
producing replies to the client requests; 

a presentation layer to structure the replies produced by the problem-solving logic layer 
in a manner that makes the replies presentable on various client devices; and 

a constraint hierarchy of multiple constraint layers, each constraint layer containing a set 
of one or more constraints that specify how the replies should be structured to customize the 
replies for specific sets of conditions. 

The Office Action again relies, in part, on columns 5 and 6 of Immerman, but Fig. 
2 of Immerman in no way discloses or suggests a multi-layer application that comprises a 
problem-solving logic layer and a presentation layer. Furthermore, Immerman in no way 
discloses or suggests a constraint hierarchy of muhiple constraint layers, each constraint 
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layer containing a set of one or more constraints that specify how the replies should be 
structured to customize the replies for specific sets of conditions. 

The rejection of claim 9 relies in part on columns 5 and 6 of Immerman. But the 
hierarchy described there does not include a multi-layer application that includes a 
problem-solving logic layer and a presentation layer. Further, the hierarchy described in 
that excerpt of hnmerman is used to construct the local run time model 90, not to 
customize replies. 

The rejection of claim 9 also identifies column 10, line 30 to column 11, line 28 
of Immerman. This passage, in part, reads: 

ID policy database 1 14 is a MgMy secure collection of security policy documents 1 10. It 
is accessed by DSAPI ID generator 108 in response to a user login request on channel 307 to 
detemiine the security domain of that user and determine the correct response. 

While this passage mentions determining a "correct response," this subject matter is not 
even remotely related to constraints that specify how replies should be structured to 
customize the replies for specific sets of conditions. To repeat, Immerman's main thrust 
is to download functionality to a client device to allow the client device to work offline. 
Thus, Immerman devotes significant discussion to this download procedure. This 
download procedure is a preparatory procedure, enabling the client device to work 
offline; as such, this procedure does not describe the use of a server system to customize 
replies for cHent devices in the manner recited in claim 9. In other words, Immerman's 
"correct response" has nothing to do with the customized replies recited in claim 9. 

As another example of the deficiency of the Immerman reference, claim 10 
(which depends on claim 9), recites that the constraint layers can be selectively added or 
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removed from the constraint hierarchy independently of other layers in the multi-layer 
application to produce different sets of constraints. In Immerman's Fig. 2, certain models 
are prerequisites of others, indicating that these models cannot be added or moved 
independently of each other. 

As another example of the deficiency of the Immerman reference, claim 30 
(which depends on claim 1), recites that the constraints are expressed as metadata. The 
Office Action refers to a broad swath of columns 10 and 11 of hnmerman as disclosing 
this feature. But the entire Immerman document does not even mention the word 
"metadata," so Immerman nowhere discloses the claimed subject matter. 

For at least the above exemplary (and non-exhaustive) reasons, the Applicant 
submits that Immerman does not anticipate any of claims 1-32, and respectfully requests 
that this rejection be withdrawn. Namely, as stated in MPEP § 2131, a claim is 
anticipated only if each and every element as set forth in the claim is found, either 
expressly or inherently described, in a single prior art reference. Verdegaal Bros. v. 
Union Oil Co. of California, 2 USPQ2d 1051 (Fed. Cir. 1987). Since Immerman does 
not set forth each and every feature, it fails to anticipate the claims under § 102. 
Moreover, for the reasons stated above, Immerman discloses a very different system than 
the claimed invention, and therefore also does not render the claims obvious under 35 
U.S.C. § 103. 

In any event, MPEP § 707.07(f) states that, "Where the applicant traverses any 
rejection, the examiner should, if he or she repeats the rejection, take note of the 
applicant's arguments and answer the substance of it" (page 700-119, Rev. 2, May 2004). 
The Final Office Action did not address the majority of the points made in the March 30, 
2005 Response, and therefore fails to comply with the policy set forth in the MPEP. If 
the rejection is repeated, the Patent Office is respectfully requested to address each of the 



25 



1 

2 
3 
4 
5 
6 
7 

9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 



points raised above. A non-exhaustive list of these points is presented again here in 
summary fashion: 

• Some of the claims are directed to a "server system." In contrast, the thrust in 
hnmerman is to download functionahty to a client device, so that the client device can 
work offline. This means that the server-centric role recited in some claims is nowhere 
disclosed or suggested by the Immerman document. 

• Some of the claims recite a constraint hierarchy that customizes an application, 
hi contrast, Immerman discloses a local run time model having component models that 
have a prescribed design dependency. But these component models cannot be said to 
customize an application in the manner claimed, given the plain meaning of the word 
"customize." 

• Some of the claims recite constraint layers that contain legally mandated 
constraints, company-mandated constraints, customer constraints, cultural constraints, 
and end user constraints. Immerman discloses none of these models. The Office Action 
has not even made clear how Immerman's models (object data store model 92, security 
model 96, indexing model 98, replication model 94, agent workflow model 99, and mail 
model 97) are being construed to meet the claim language. 

• Some of the claims recite a constraint resolver to resolve the constraint layers so 
that operation of the application is constrained by a sum of the constraints in the layers. 
There is absolutely no hint in Immerman that these models might conflict with each 
other. Hence, there is likewise no suggestion that Immerman's system includes a 
constraint resolver to cope with such conflicts. 

The Examiner is respectfully requested to address each of these points - and to 
particularly address these points in a manner which does not simply involve pointing to a 
multi-paragraph passage in hnmerman. Due to the complexity and length of the 
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Immerman document, prosecution will be advanced if the Patent Office can expressly 
name the features of hnmerman that are being construed to meet the claim elements. 
Currently, the Patent Office's correlation between the specific features recited in the 
claims and the features of the Immerman reference is very unclear. 

New Claims 

This Response add new dependent claims 33-44. These claims are allowable at 
least by virtue of their incorporation of the subject matter of the independent claims from 
which these claims respectively depend, hi addition, claims 33-44 add new features 
which further distinguish the claimed invention over hnmerman. 

For example, claim 33 recites that "each constraint layer represents a different 
source entity that customizes the application." The different models shown in Fig. 2 of 
Immerman do not represent different source entities that customize an application. 
Likewise, different layers in a seciuity model do not represent different source entities 
that customize an application. 

As another example, claim 39 recites, in summary, that the hierarchy comprises 
each of: a constraint layer that contains legally mandated constraints, a constraint layer 
that contains company-mandated constraints, a constraint layer that contains customer 
constraints, a constraint layer that contains cultural constraints, and a constraint layer that 
contains end user constraints. Since hnmerman does not disclose any one of these layers 
individually, it certainly does not disclose the combination of these different layers. 
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Conclusion 

The arguments presented above are not exhaustive; Applicant reserves the right to 
present additional arguments to fortify its position. Further, Apphcant reserves the right 
to challenge the alleged prior art status of one or more documents cited in the Office 
Action. 

All objections and rejections raised in the Office Action having been addressed, it 
is respectfully submitted that the present application is in condition for allowance and 
such allowance is respectfully solicited. The Examiner is urged to contact the 
undersigned if any issues remain unresolved by this Amendment. 

Respectfully Submitted, 

Dated: 2/15/2006 By: 

David M. Huntley 
Reg. No. 40,309 
(509) 324-9256 
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